TPM 2.0 · Secure Boot · Linux Encryption

TPM and Disk Encryption

The project studied the Linux boot process, UEFI Secure Boot, LUKS block encryption, TPM 2.0 key handling, PCR-based sealing, and practical tpm2-tools workflows inside a Hyper-V virtual machine with vTPM support. TPM key sealing and TPM-based file encryption were demonstrated successfully, while the final LUKS disk encryption integration remained incomplete due to cryptsetup policy handling and mounted partition errors.

View References →

Overview

A TPM is a hardware root of trust used to protect cryptographic material and measure selected parts of the boot process. Through Platform Configuration Registers, the TPM can bind a sealed secret to a measured boot state. If firmware, bootloader, Secure Boot state, or selected platform measurements change, the sealed object may no longer be released.

In combination with LUKS2, TPM2 can be used to unlock encrypted Linux volumes during boot when the measured platform state matches the expected policy. In this project, that workflow was investigated with tpm2-tools and cryptsetup. TPM sealing and RSA based file encryption were demonstrated successfully, while the final disk encryption script reached a clear but incomplete implementation stage.

TPM Key Hierarchies

EndorsementPrivacy-sensitive, persistent
OwnerStorage hierarchy, persistent
PlatformBIOS/SMM, persistent
NullEphemeral, lost on reboot

Key Concepts and Implementation

1. CIAAN – the five security properties+

Security in embedded systems is often evaluated against five core properties. Confidentiality protects information from unauthorised parties through encryption and access controls. Integrity ensures data has not been tampered with, using hashing or digital signatures. Availability ensures authorised users can access systems consistently. Authenticity verifies that communication originates from a trusted source. Trustworthiness (non-repudiation) ensures that a party cannot deny having sent or received a message.

Technical detail

C – Confidentiality:   access is restricted
I – Integrity:         information is unchanged
A – Availability:      service is up and running
A – Authenticity:      the source is authenticated
N – Non-repudiation:   information is reliable

These five properties form the foundation for evaluating whether a security mechanism is sufficient. TPM supports several of these goals, especially confidentiality of key material, integrity measurement through PCRs, authenticity through attestation-style workflows, and non-repudiation related cryptographic evidence. It does not guarantee availability by itself and must be combined with correct system design.

2. Boot process – from power button to kernel+

When the power button is pressed, the CPU jumps to a fixed address in flash memory and reads the UEFI firmware. UEFI replaced legacy BIOS in modern systems because it provides richer boot services, larger disk support, and Secure Boot support. The firmware initialises hardware, then hands off to GRUB, which loads the Linux kernel image (vmlinuz) and the initial RAM disk (initramfs). The initramfs prepares the real root file system before the full OS takes over.

Technical detail

Power on
  └─ CPU reads UEFI from EEPROM/FlashROM
       └─ UEFI initialises hardware
            └─ MBR / GPT → GRUB stage 1 (boot.img, 446 bytes)
                 └─ GRUB stage 1.5 → core.img
                      └─ GRUB stage 2 reads grub.cfg
                           └─ Loads vmlinuz + initramfs
                                └─ Kernel mounts root file system

The firmware itself is stored on the platform, while the bootloader, kernel, initramfs, and root file system are usually read from disk. If these disk-based components are not protected, physical access can allow offline modification. TPM-based sealing and disk encryption reduce this risk by releasing secrets only under expected boot measurements.

3. initrd vs initramfs+

Two mechanisms exist for loading a temporary root file system before the real root is mounted. initrd is the older RAM-disk based mechanism. initramfs is the modern early-userspace mechanism based on a cpio archive unpacked into memory. In encrypted Linux systems, initramfs is important because unlock tools and TPM integration must run before the real root file system is mounted.

Technical detail

initrd   (kernel ≤ 2.4):  fixed-size block device, I/O buffered
initramfs (kernel ≥ 2.6):  cpio archive → tmpfs, fast direct access

initramfs advantage: no fixed size, better memory efficiency,
  supports encrypted root partition unlock at early boot

For disk encryption with TPM, initramfs is critical because it must contain the tools and hooks to unseal the encryption key from the TPM before the encrypted root partition can be mounted.

4. UEFI Secure Boot+

Secure Boot is a UEFI feature that verifies cryptographic signatures of every piece of boot software before execution. It uses three key types: the Platform Key (PK) at the top of the trust hierarchy, the Key Exchange Key (KEK) for signing updates to the allowed database, and the Database Key (db) for verifying bootloaders and drivers. A Forbidden Signatures Database (dbx) blocks revoked binaries.

Technical detail

Key hierarchy:
  PK   – Platform Key (top-level, signed by own private counterpart)
  KEK  – Key Exchange Key (used to update db / dbx)
  db   – Database of allowed bootloaders, drivers, shells
  dbx  – Forbidden signatures database (revocation list)

Verification:
  Binary hash (SHA-256) checked against db entries
  Match in db  →  allowed to execute
  Match in dbx →  execution refused

Secure Boot was disabled in the Hyper-V VM to avoid additional signing complexity during the experiment. In a production setup, Secure Boot and TPM-based LUKS unlocking can coexist, but the bootloader, kernel, initramfs, and related hooks must be signed and trusted correctly.

5. TPM – Trusted Platform Module+

TPM is a cryptographic co-processor attached to the motherboard. It can generate key pairs, store them, perform hashing and signing, encrypt and decrypt data, and generate random numbers. Keys belong to one of four hierarchies: Endorsement (privacy-sensitive), Owner (storage, used by platform owner), Platform (used by BIOS and SMM), and Null (ephemeral, lost on reboot). Keys in the Endorsement, Owner, and Platform hierarchies survive reboots; Null hierarchy keys do not.

Technical detail

TPM capabilities:
  tpm2_createprimary   – create primary key under a hierarchy
  tpm2_create          – create child key (public + private parts)
  tpm2_load            – load key into TPM
  tpm2_evictcontrol    – persist key to a permanent handle (e.g. 0x81010001)
  tpm2_unseal          – retrieve sealed secret using stored key
  tpm2_rsaencrypt      – encrypt with RSA key
  tpm2_rsadecrypt      – decrypt with RSA key
  tpm2_getrandom       – generate random bytes
  tpm2_getcap          – query TPM capabilities

The TPM seed is an internal secret value used as a root for deriving TPM-protected objects. It is not exposed outside the TPM. Private key material is designed to remain non-exportable when the object attributes are configured accordingly.

6. PCR – Platform Configuration Registers+

TPM contains 24 Platform Configuration Registers (PCRs) that hold cryptographic hash measurements of the system at boot time. Each PCR covers a specific part of the boot chain. When hardware, firmware, or bootloader changes, the PCR values change. This chain of trust allows TPM to detect tampering and refuse to unseal an encryption key if the boot state has changed.

Technical detail

PCR 0  – CRTM, BIOS code, Host Platform Extensions
PCR 1  – Host Platform Configuration (CPU, RAM replacements)
PCR 2  – Option ROM Code
PCR 3  – Option ROM Configuration and Data
PCR 4  – IPL Code (MBR)
PCR 5  – IPL Configuration and Data (partition changes)
PCR 6  – State Transition and Wake Events
PCR 7  – Secure Boot state (PK, KEK, db, dbx)

Hash algorithms supported: SHA1, SHA256, SHA384

A TPM policy can bind a sealed secret to specific PCR values. If the machine boots with the same software stack, PCRs match and the key is released automatically. If selected measurements change, the policy may no longer match and the secret may not be released.

7. LUKS – Linux Unified Key Setup+

LUKS is a disk encryption specification for block device encryption on Linux. It maintains a header with an encryption key table, allowing multiple passphrases or key slots. Each slot can hold a different key that unlocks the same encrypted volume. LUKS works at the block device level, so the file system inside is completely unaware of the encryption.

Technical detail

Partition layout in lab:
  /dev/sda1  – 512 MB  EFI (vfat, unencrypted)
  /dev/sda2  – 49.5 GB root filesystem target for LUKS

Encryption setup (cryptsetup):
  cryptsetup luksFormat --type=luks2 /dev/sda2
  cryptsetup open --type=luks2 --tpm2-policy=0:... /dev/sda2 encrypted_disk
  mkfs.ext4 /dev/mapper/encrypted_disk
  mount /dev/mapper/encrypted_disk /mnt/encrypted

TPM and LUKS are complementary. TPM provides hardware-level key storage and PCR-based boot measurement. LUKS provides the encrypted container. The project attempted to combine both, but the final disk encryption step was not completed successfully.

8. Hyper-V vs VirtualBox vs QEMU – hypervisor choice+

Three virtualisation options were evaluated. Hyper-V was selected because Generation 2 virtual machines support vTPM. VirtualBox was less suitable for this lab goal, while QEMU could emulate TPM but required additional setup scripts and manual configuration.

Technical detail

Hyper-V:      Type 1, hardware-level, vTPM in Gen2 VMs  ✓ chosen
VirtualBox:   Type 2, host OS dependent, no native vTPM
QEMU:         Full emulation, TPM emulatable but setup complex

Note: Hyper-V not available on Windows 10 Home.
Workaround: batch script to enable via DISM:
  Dism /online /enable-feature /featurename:Microsoft-Hyper-V-All

Generation 2 was selected in Hyper-V specifically for vTPM support. After creating the VM and installing Ubuntu, Secure Boot was disabled from the Security section and TPM was enabled before first boot.

9. First steps with TPM – key creation and sealing+

The initial exercises followed a clear sequence: clear the TPM state, create a primary key under a hierarchy, generate random bytes as a secret input, create a sealed object (public and private parts) bound to that secret, load both parts into the TPM, and persist the loaded object to a permanent handle. The sealed object can only be unsealed using the correct key handle, producing the original secret as output.

Technical detail

# Step-by-step (ECC primary, sha256, seal secret bytes):
tpm2_clear
tpm2_createprimary --quiet --hierarchy=o --key-algorithm=ecc \
  --hash-algorithm=sha256 --key-context=prim.ctx

dd if=/dev/urandom bs=1 count=32 status=none > KEY_IN

tpm2_create --hash-algorithm=sha256 --public=seal.pub \
  --private=seal.priv --parent-context=prim.ctx -i- < KEY_IN

tpm2_load --parent-context=prim.ctx --public=seal.pub \
  --private=seal.priv --name=seal.name --key-context=seal.ctx

tpm2_evictcontrol --hierarchy=o --object-context=seal.ctx 0x81010001

tpm2_unseal -c 0x81010001 > KEY_OUT
sha256sum KEY_IN KEY_OUT   # must match

tpm2_evictcontrol was used to assign a persistent TPM handle to the loaded object. This does not export the key or make it portable. It only keeps a persistent TPM reference so the object can be addressed later without repeating the full loading workflow.

10. Simple file encryption with RSA key+

A practical file encryption exercise created an RSA-2048 key pair, loaded both parts into the TPM, encrypted a text message using the public key, and decrypted it using the private key held in the TPM context. The encrypted binary file is not human readable and can be recovered through the matching TPM-loaded key context in this lab setup. This exercise demonstrated the practical difference between a software-visible file and a TPM-mediated key operation.

Technical detail

# Create RSA primary
tpm2_createprimary -c primary.ctx

# Create RSA child key pair
tpm2_create -C primary.ctx -G rsa2048 -u key.pub -r key.priv

# Load into TPM
tpm2_load -C primary.ctx -u key.pub -r key.priv -c key.ctx

# Encrypt a message
echo "Ich bin extra dip-sauce" > mesg.dat
tpm2_rsaencrypt -c key.ctx -o mesg.enc mesg.dat

# Decrypt
tpm2_rsadecrypt -c key.ctx -o mesg.ptext mesg.enc
cat mesg.ptext   # → "Ich bin extra dip-sauce"

The mesg.enc file contents are binary and unreadable. The mesg.ptext file is the recovered plaintext. This confirms that encryption and decryption worked through the TPM context in the lab workflow.

11. Disk encryption script – combining TPM policy with LUKS+

The final script attempted to combine a TPM policy with LUKS formatting and mounting. The implementation did not complete successfully. The log showed errors related to TPM policy handling, cryptsetup usage, and the target partition already being mounted. Therefore, this part should be presented as an incomplete integration step rather than a finished full disk encryption setup.

Technical detail

#!/bin/bash
disk=/dev/sda2
tpm_handle=0x81010040

# Verify handle exists
tpm2_readpublic -c $tpm_handle &>/dev/null || exit 1

# Create PCR-bound policy (covers PCR 0–7)
tpm2_createpolicy --policy-pcr -l sha256:0,1,2,3 \
  -L pcr0.policy -L policy.digest

# Warn and format
cryptsetup luksFormat --type=luks2 $disk

# Open with TPM policy
cryptsetup open --type=luks2 \
  --tpm2-policy=0:$PWD/policy.digest $disk encrypted_disk

mkfs.ext4 /dev/mapper/encrypted_disk
mount /dev/mapper/encrypted_disk /mnt/encrypted

The final errors were caused by policy handling, cryptsetup usage, and the mounted state of the target partition. The intended structure was clear, but the implementation remained incomplete and should not be described as production-ready.

Tools and Libraries

  • tpm2-tools – command-line TPM 2.0 utilities
  • cryptsetup – LUKS disk encryption management
  • Hyper-V – Type 1 hypervisor with vTPM support
  • OpenSSL – software cryptography library used as a comparison point
  • tpm2-tss, FAPI, ESAPI, SAPI – TPM software stack layers
  • Ubuntu 20.04 LTS – guest OS running inside the VM

Key Challenges

  • Finding useful, consistent documentation and guides online was difficult.
  • Disk must be unmounted before LUKS formatting – mounting state caused errors.
  • PCR policy arguments for cryptsetup open required precise syntax.
  • Secure Boot adds signing requirements for bootloader, kernel, initramfs, and related hooks.
  • Hyper-V requires Windows 10 Pro or Enterprise for native access.

References and Materials

These sources were used while preparing the TPM background theory, hypervisor comparison, Secure Boot explanation, and practical tpm2-tools exercises.

OpenSSL – What Is It and How Does It Work?

Explanation of OpenSSL as a software cryptography library for TLS, certificate handling, and key related operations. OpenSSL is not a TPM replacement, but it is useful as a software-side comparison point.

https://www.ssldragon.com/blog/what-is-openssl/

ACPI – Wikipedia

Advanced Configuration and Power Interface standard used by operating systems to discover and configure hardware components.

https://en.wikipedia.org/wiki/ACPI